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[57] ABSTRACT 

A method for supporting speculative execution includes 
designatiDg operations as speculative or non-speoilative, 
and then deferring excqptions generated by speculative 
operations while immediately reporting exceptions by non- 
speculative operations. If a speculative operation uses a 
result of a speculative operation that has generated an 
exception, the exception is propagated. Deferred exertions 
are detected and reported using a check operation either 
inooiporated into a non-speculative operation or inserted as 
a separate check operation. A system for supporting specu- 
lative execution includes a functional unit for recogniziDg a 
speculative <^)eration and defening any exceptions gener- 
ated by such an operation. The functional unit may defer an 
exception by stodng information indicating an error has 
occurred in the register file. To check for deferred 
exceptions, the functional unit then reads the register file. 

19 Claims, 2 Drawing Sheets 
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METHOD AND SYSTEM FOR DEFERRING 
EXCEPTIONS GENERATED DURING 
SPECULATIVE EXECUTION 

REFERENCE TO PARENT CASE 

This is a cootinuation-io-pait of patent applicatioD Ser. 
No. 087192,758 to Rau and Schlanskcr, entitled "METHOD 
OF IMPROVING PERFORMANCE OF PARALLEL- 
raOCESSOR COMPUTER USED TAGGED OPERANDS 
TO CONTROL EXCEPHON," filed Feb. 7, 1994, now 
abandoned which is hereby incorporated by reference, and 
whidi is a continuation of 07/628041, filed Dec, 14 1990. 
now abandoned. 

FIELD OF THE INVENTION 

This invention generally relates to code optimization in 
computer scheduling and more particularly the architectural 
support for such optimization. 

BACKGROUND OF THE E^VENTION 

The performance of a computer system may be enhanced 
by optimizing the code of a coit^^uter program so that die 
computer can execute the program more quiddy. One of the 
steps In optimizing a program is a process called scheduling. 
Scheduling is a process where the series of computer opera- 
tions that con^irise a program are organized for execution. 
During the scheduling process, operations of the program 
may be arranged, eliminated, or moved to make the program 
run more efficiently for a particular CPU design. Generally, 
there are two forms of scheduling: dynamic scheduling 
performed by the hardware during execution of a program, 
and static scheduling performed by a con^iler before execu- 
tion. Eitha of these techniques, or a combioatioD of both, 
may be used to schedule operations in a computer program 
fox processing by a coa4>uter system. 

A ccHDputer program consists of a series of instructions to 
be carried out by a central processing unit (CPU) in the 
computer system. A typical program is written in a high level 
language and then conspiled into a series of instructions 
con^atible with the instruction set architecture of the CPU. 
A program, however, may also be directly written in 
^'machine language** according to the instruction set archi- 
tecture of the computer. The instruction set architecture 
defines the format or encoding of operations, including 
<^erators and operands in an instruction. Depending on the 
structure of the CPU and the scheduling techniques 
involved, each instruction may have one or more operations. 
An operation includes an operator encoded in an opcode 
representing functions such as add, subtract, load, store, 
branch, etc. Additionally, an operation identifies the oper- 
ands and the results of the operation. To accomplish this, the 
operation typically includes a code identifying the location 
such as a regista of an operand or operands. It is these 
operations that are organized for execution by the CPU using 
the c^timization techniques. 

There are different levels of optimization. One level 
optimization is local optimization where code within a 
straightline code fragment or "basic block" is manipuiated to 
run more efficiently. Exac^)les of local optimization tech- 
niques are common subexpression dimination and constant 
propagation. Another level of optimization is global optimi- 
zatioo which includes extending local optimization tech- 
niques across conditional brandies in a program and further 
includes transformations for optimizing loops. One fom of 
global optimization is code motion. An exan^le of code 



motion is removing code from a loop that computes the same 
value each iteration of a loop. A third level of optimization 
is machine dependent optimization. Machine dq^endent 
optimization involves manipulation of code to take advan- 

s tagc of specific architectural attributes of the CPU. For 
example, if the CPU has a pipelined functional unit for 
executing instnictions concurrently, then code can be reor- 
dered to Iraprovc pipeline performance. 
To optimize a program, code may be moved above a 

1<> conditional branch in a scheduling ]^ocess called specula- 
tive code motion. Speculative code motion refers to the 
movement of an instruction above a conditional branch that 
controls its execution. The execution of a "speculative" 
instniction may be referred to as a speculative or antidpa- 
tory execution because the instruction is executed before it 
is known whether the instruction will actually be used in the 
program. Speculative code motion can enhance instcuctioa 
level parallelism. Because many instructions have a long 
latency, meaning they take several dock cycles to execute. 

^ it is advantageous to execute an instruction speculatively. 
The delay that an instruction would othersvise cause can t)e 
minimized by issuing the instruction in advance. Speculative 
code motion may also be useful in other optimizations such 
as redundancy elimination. 

^ While speculative execution has the potential for enhanc- 
ing performance, it has not been effectivdy incremented 
due to the problems in dealing with errors in speculative 
instnictions. If a speculative instruction generates an error, 
the enor should be deferred and should only be reported if 

^ the speculative instruction is actually used in the program. 
Otherwise, axon that would not have been reported in the 
original program would be reported, and the behavior of the 
program would be changed. 

Existing optimization tedinlques have not effectivdy 
addressed the problems with moving code across conditional 
branches. One way to address the error problem is to prevent 
speculative code motion for instructions that may generate 
an error. This solution has serious limitation because only 

^ non-error generating operations may be moved. Another 
potential solution is to ignore all errors. This solution is 
unsatisfactory because it prevents error handling or report- 
ing. 

SUMMARY OF THE DWENTION 

45 

To address die drawbacks and limitations of existing 
optimization techniques, the invention provides a method 
and system for providing suf^rt for speculative execution. 
In one embodiment the method indudcs providing two 

so versions of the operations in the instruction set, a speculative 
version and a non-speculative version. Operations that are 
moved above conditional brandies are encoded as specula- 
tive (^)erations. Both speculative and non- speculative opera- 
tions are then executed by a CPU. If a speculative operation 

55 generates an exception, then the excq)tion is deferred. An 
exception from a speculative operation may be propagated if 
the result oi a first speculative operation is used as an input 
to a second ^>eculative operation. If a non-speciilative 
operation generates an exception, the exception is handled 

£0 or reported immediately. The step of executing ' a non- 
speculative instruction may include checking fcH* deferred 
exceptions. If a deferred exception is detected, then the 
exception is reported. 
In a second embodiment, the method includes providing 

65 natively speculative oporations in the instniction set These 
natively speculative operations are treated as speculative 
operations for scheduling and for deferring exceptions. 
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However, these operations do not need to be identified as FIG. 2 is a hlock diagram of a central processing unit 

speculative operations by encoding them as such in the according to an embodiment of the invention, 

opcodes. Rather, die CPU treats a predetcnnincd set of piG. 3 is a diagram of an instruction having multiple 

operatioDs as natively speculative. To enhance the coI^^Jat- operations 

ibility of the CPU with existing progrwns thcCPU can also 5 piG. 4 is a flow diagnim of a method for supporting 

mdude two ^,"^2^^ ^P«^"l^tive execution a^g to an embodiment of the 

predetcnmncd set of operations are natively speculative, and 

a second mode where the predetermined set of operations invcnuon. 

are non-speculadve. As In the first embodiment above. DETAILED DESQUFTION 
exceptions for speculative operations are deferred while 

exceptions for non-spcculativc operations are reported An embodiment of the invention generally provides a 

immediately. method and system far supporting ^eculative execution. 

A system for supporting speculative execution may be The following description begins with a general c^lanation 

implemented in a CPU including a functional unit and of speculative execution. Next, systems for supporting 

register file. During execution of operations in a program* speculative execution are described. Finally, a mrthod for 

the functional unit of the CPU recognizes whether an supporting qjcculative execution is described according to 

operation is speculative or non-speculative. If a speculative embodiments of the invention. 

operation generates an excq>tion. the functional unit stores Speculative code motion can be used eflfectively in CPUs 

inf oiroation in a rcgUtcr in the register file indicating that an j^^^ing concurrent processing c^biUty. A GPU can execute 

exception has been defared. In one ua^lementation, toe ^ ^^^^ opaations more quickly by issuing separate 

reglst^s in the register file may Include an ™^ tag ^ ^ operations at the same time or overlapping the execution of 

identifymg whether an cxocpuon has ^\f^^^^ orations. A typical CPU executes an operation in sUiges. In 

non-speculauve operation may be used to check for defied ^ having more than one functional unit for executing 

exceptions. In the process of executing sudi an operation, " u«vuib uiou vii^ iu«^,iiv/«a» uiix% ^ 

thrfiinctional unit checb the regista file to ditomine opa^ons the CPU can Uisuc multiple operations and 

whether .n exception hasbeendefcS«liran«c.,rtion has 25 to multiple op«^ons smulU- 

r ^ r A^Tt ^ I ^ +K neously. In a pipelined processor, the CPU includes a 

been defcneA the functional unit rqports the ««ptioo. ^ ^ ^ ^ 

The method and system for provi«Ung support for specu- Une Pipelining reduces overall processing time of 

Uuve execution provide several advantages Exceptions ^ ' eiiaMing the processor to execute different 

gcneiated by speculative operaUons are ignored unless the ^^^^^^ instructions simultaneously. A CPU can 

speculative opwatlon is actually used in the program. As a 30 .^^^^ ^ functional unite or pipelining, or can 

result, the computa system achieves the perfonnance gains combine botii fcahms 

provided by speculative execution without losing full error j 

detection and reporting capabiUties. Employing the ^ ooncuirentj^ocessmg CPUs speculaUve code mot^ 

approach of oneei^xiiint.%eculativeex^ti<i .^y be «n optimize perform«.ce by addressmg l^ency prob- 

• 1 * J • • *_ «u-**^«- c,^^^ IK Icm. Latency is the tunc required for the CPU to complete 

implemented m an mstruction set architecture where specu- 35 "^u^j^ ^ ^ ^ , . ^ * „ 

~j . . *j • .^A^ an operation. An operation with long latency can stall or 

lative and non-speculative versions are provided for several vy«awvu, ^ ^ / 

operations. If. h^ever. such an approad. is not possible in ^^^y^ °f " P«;oB«n» while (he CPU w«^ to 

aVrtcular instruction set archiSSire. speculative execu- «»0P«»«J°" brfore begimung another. WMhout 

tioVam be supported by treating sey.i^ operations as speculative code mouon the CPU muse evaluate a hrandi 

natively specuUU\^th(itchSs" specify « 40 condition before issuing any of the operations aft« the 

nrl/ » o branch. By moving an cpcraUon above the conditional 

^''f™'', . L . ... . . ^fi* tarandi, the CPU can issue the operation in advance as a 

This alternative approach is espemUy usrfulm rettofi^^ speculative operation. In a CPU \^th multiple functional 

tmganexistinginstiuctions«archltectiiretosuppo^ pipeuLg, the CPU can process the speculative 

lative execution^Torrtroflt an «^ operation .incunentty with other iemtioos. If ftebnmch 

of a CPU can be modified to support speculative execution 45 °P ^ ^^^^^ ^ ^^^^ ^ ^ 

whde n^tammg ^^ff»iosv^acn f<^ fl„„^ be dtoer partially or entirely completed by ttie time 

an existing insmiction set ych«ectiir(^Tlie u.st™^^ sHis ^ operation's ^ginal position, 

not matenaUy changed^but instead. Ae hardwae s«nanti« spcJSative code motion adS the laten^r problem by 

of the op«ations «« changed to add support for defemng eliminating ttie staU in execution of a^ 

and cheddng for deferred exceptions generatedt^^ so ^ 8 ^ ^ 

lative op»ation, In ^ »PP^ 'S^. ^ Pressors ^ concurrent processing capability because 

modes of operation: a fint modc wh« operations are ^ u^'ca^ to process 

non-speculative; and a secoiidrrKxlewhere 50^ multiple operations « once. 

are ttcated as natively speculative. The second mode differs , ^. . ^ • „ 

from the first in Uiat exceptions are deferred for natively SS Tbt process of executing specuUtive msttuetions is caUed 

speculative, operations. By supporting these two modes of speculative execution. Speculative code motion may be 

««ation. the CPU is compatible with the Wnaiy form of unplementcd in a variety of scheduling techniques to pro- 

prqgrams compiled for anaistfng instruction set architec- vide support for speculative execution. SpecuUtive code 

Src whether oTnot ttie programs have been optimized using motion may be used in connection with multiple ftmctional 

speculative code motion. « ""it pipelined CPUs to exploit paraUehsm and tiiereby 

Further advanti^ses and feahnes of the invention will optimiw a propam. Speculative code m^^ 

become apparent to tiiose skilled in the art from the foUow- conjunction widipjirtuil redundant ^^T?" aH?f™^' 

ing descSion and accompanying drawings. « ^ \ 

" ^ "y^^ » » schedulmg support, speculative execution also requires 

BRIEF DESCRIPTION OF THE DRAWINGS architectiiral support 

FIG. 1 is a block diagram of a computa system in whidi To implement speculative execution, two primary issues 

an embodiment of the invention may be inqdemented. must be addressed: speculative code motion, and exception 
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detection and rq)oiting. In this context speculative code 
motion refers to the scheduling technique used to move 
operations above their associated branches. Exception detec- 
tion and reporting relates to scheduling in view of possibility 
that a speculative operation may generate an error. 
Additionally, it refers to detecting and reporting errors 
generated by speculative operations. Because these Issues 
are closely related to scheduling, tfiey are discussed first in 
the context of scheduling to support speculative execution. 
Next, a preferred method of exception detection and repeal- 
ing is discussed. 

Before a program is executed^ a scheduler optimizes die 
program by using speculative code motion and perhaps other 
(^timization techniques to deaease processing time of the 
program. The scheduler may be dynamic or static* or may 
include a combination of compiler and hardware scheduling. 
Any of a number of well known scheduling techniques may 
be used, including but not limited to trace scheduling, 
modulo scheduling, and enhanced pipelining. Regardless of 
the scheduling technique used, the scheduler should include 
support fra- speculative code motion. 

Speculative code motion includes moving an operation 
from its home basic block to a previous basic block. A basic 
block is a straight line sequence of operations followed by 
a single branch. The home basic block of an operation is the 
basic block in which it resides in the original progranu The 
previous basic blocks for a given basic block are all the basic 
blocks that can t^nch to the given basic block or that 
sequentially precede the basic block. During scheduling, an 
operation may be moved across a branch to a set of previous 
basic blocks. The operation is moved such that the operation 
will always be executed before any use of its result will 
occur. To satisfy this requirement, the operation may be 
moved to multiple preceding basic blocks. This general 
technique of speculative code motion may be used in variety 
of scheduling methods. 

One method for scheduling across basic blocks is super- 
block scheduling. A superblock is a block of opOTtions 
where control can only enter from the top but may exit at one 
or more points. Superblock scheduling consists of two steps: 
dependence gr^ construction and list scheduling. The 
dependence graph represents the control and data dq^enden- 
des between operations in a superblock. Using control 
dependencies, the scheduling technique can address restric- 
tions on speculative code motion. In this context, the two 
primary restrictions on moving an operation above a branch 
are 1) the result of the operation is not used before it is 
redefined when the branch is taken; and 2) the operation will 
not cause an exception that alters the results of the program 
when the branch is taken. 

Different scheduling techniques using the superblock 
model may address these general restrictions on speculative 
code motion. For most scheduling techniques, the first 
restriction can be overcome using compiie-time renaming 
transformations. After control dependencies are eliminated^ 
list scheduling using the dependence graph, instruction 
latencies, and resource constraints may t>e performed to 
determine how operations arc scheduled. The problem of 
exceptions may be handled diffcrentiy dqjending on the 
scheduling technique. 

An exception is an error such as arithmetic undoflow or 
overflow, an undefined instruction, or a memory access 
error. When an operation causes an excqition in a non- 
speculative system, die exception is typically reported 
immediately, and the CPU branches to an exception han- 
dling routine of the operating system. If speculative opera- 
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tions immediately reported an excqjtion, then the CPU 
would have to perform potentially unnecessary and seman- 
tically incorrect error handling for speculative operations 
that may ultimately not be in the execution path of the 
5 program. 

The preferred way of dealing with exceptions in specu- 
lative (^)a-ations is to defer reporting of the exceptions. 

The excq>tion is only reported if the operation is actually 
executed in its home basic block. By deferring such 
^0 excqitions, unnecessary exception handling is avoided The 
computer system provides enhanced performance and pre- 
serves the semantics of the original program. 

If the result of a speculative operation that generates an 
exception is used as an input to a second speculative 
operation, then the exception is propagated to tiie second 
operation. An exception will be propagated through any 
speculative operations that use the result of a speculative 
operation generating an error. These propagated exceptions 
will only be reported if the exception is propagated to an 

operation that is actually used in the execution path of the 

20 

{vogram. 

To support deferred reporting of exceptions, a system 
according to an embodiment of the invention includes a 
means for deferring the excq>tion. An exception may be 

^ deferred using a buffer or a tag in the register to kcq> a 
record that an error has occurred. The system also includes 
a means for reporting a deferred cxcqition. The home block 
of a speculative instruction includes an operation for check- 
ing whether an excq>tion has occurred. This operation may 

^ be an additional check operation inserted in the home block 
or may be incorporated into a non-speculative operation in 
the home block. An implementation of these aspects of a 
computo" system are described below. 

As an overview, FIG. 1 illustrates a generalized block 

33 diagram of a computer system 20 in which a system accord- 
ing to the invention noiay be embodied. The computer system 
20 includes a CPU 22 coupled to memory 24 and one or 
more peripheral devices 26 via a system bus 28. The system 
t>us 28 may carry data and control signals to the CPU 22, 
memory 24 and peripheral devices 26, The memory 24 
preferably includes Random Access Memory (RAM), but 
may also be implemented witii Read Only Memwy (ROM), 
or a combination of RAM and ROM. Tlie memcny 24 stores 
data for one or more programs that may be executed in the 
con:q)uter system 20. 

FIG. 2 is a block diagram of a CPU 22 according to an 
embodiment of the invention. The CPU 22 includes multiple 
functional units 30, one or more register files 32, and an 
instruction unit 34. The register files 32 typically contain 

50 several general purpose registers 36 for storing values, 
addresses and possibly other data. In addition, the registers 
32 in the register file 36 may include an error tag bit 38 for 
identifying whether an exception has occurred. The use of 
the error tag bit 38 in speculative execution will be discussed 

33 in further detail below. 

The architecture of Uie CPU 22 may vary. This particular 
architecture merely depicts the high level hardware design 
of a CPU 22 according to one possible enobodiment. Specu- 
lative execution Implemented according to the invention can 

60 provide perfoimanoe improvement in a variety of CPU 
designs. Including in particular, CPUs with multiple func- 
tional units or CPUs with multiple pipelined functional 
units. Speculative execution is particularly effective in 
enhancing perfonnance in superscalar or Very Long Instruc- 
ts tion Word (VLIW) computers. 

In the process of running a program, the CPU 22 carries 
out a series of instructions stored in memory 24. The 
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instnictioa unit 34 fetches ao instiuctioii from memory via ated by the opeiation will be reported or deferred. If a 

the system bus 28 and then decodes the instiuctioiL D^nd- non-speculative operation generates an error, the functional 

ing on the type of CPU and/or the scheduling method used, unit 30 rcpotts the eiror immediately. If a speculative 

an instructioD may have more than one operation. The Instmction generates an exception, on the other hand, the 

instruction unit 34 issues operations to a functional unit 30 5 functional unU 30 will defer reporting the exception. In the 

or to multiple functional units (shown as stacked boxes in exception wiU only be reported if the result 

FIG. lyvh^ instruction unit 34 sends control signals to a *e opcxaUon is actually used in its home basic block, 

functional unit 30 to cany out die operation or operations in A second embodiment of the invention provides a system 

an instruction. In response to these control signals, the supportmg speculative cxeaition in a mimmum instruc- 

functional unit 30 reads daU such as address or value from lO set architecture. In contrast to the first embodiment this 

the appropriate registers in the register file 32 and performs f««>«^ embodmu.nl supports speaUative « without 

ao op^ation. For some operations, the functional unit 30 "»cludmg opcodes for sp^adve operations. Instead, the 

writ^a result back to thercgister file 32. For a memory fy^^*^ ^'^^ * number of predetenmned ppemUons m an 

store operation, the function^ unit 30 reads a memory ^ '^T, ^^^^'T^^.^^^^ 

addresrandavaluestoredintheregisterfile32andtransfers 15 ^<^^' ^ ^^^^ ^ ^/l"*?"*^^ 

the value direcdy to memory 24. embodmient also includes architectural support for 

^ „, ^ ^^ .r ^ ..ftu- deferring exceptions from speculative operations and for 

FIG. 3 iUuslrates the format of an instiuctlon 40 havmg these deferred exce^ons. 

multiple operations. The instruction includes three ^ embodiment, the scheduler and CPU may 

jTanTsSg^^^^^^ - rr^r^^^'^r^^ru^ 

44, and ^o source register fields 46, 48 The second ^ ^^^^ operations or operations 
^emtionhasan visible outside the CPU should gen'^y not be executed 

54, HnaUy, the third operajonha^^ specuktively. All of die operations thit are not visible 

single source register field 58. Tlie source ^egistc^ ficWs ^ ^ ^ ^ ^ speculative 

spedfy the loaition of the mputs to the operation and Ac ^^^^^ ^ ^^^^^^ ^^^/^ 

destinatoon register field specifies the location of the result. ^^^^ ^ To sifl)port speculative execution in this 

These fliree operations provide an example of a typical embodiment, natively speculative operations arc scheduled 

instruction. The first operation is a arithmetic ADD opera- ^ speculative operations, and die CPU hardware includes 

tion in which the functional unit 30 reads values stored in support for deferring and reporting dcf orcd exceptions from 

registers Rl and R2, adds them, and writes the result to operations. Whfie a predetermined set of a operations 

register R3. The second exan^le operation is a memory treated as natively speculative in the CPU, operations 

operation 50 in which the first register R4 stores an address visible outside the CPU remain n on- speculative. An 

and the second register R5 stores a value. The functional unit example of an operation visible outside the CPU is a 

30 reads die address and value from tiic registers and stores memory store. It is considered to be visible outside die CPU 

the value in memoiy 24 at the ^>ecified address. The tiiird because it interacts widi memory outside the CPU, and more 

exaii5)le operation is a simple move (MOV) operation. To specifically, involves overwriting a location in memory 24. 

support speculative execution, the hardware semantics of jj ^ preferable to execute such an operation specula- 

diis operation may be modified so that die operation may be ^ ^^^^ because it may affect anotiicr process interacting with 

used to check for deferred exceptions, game memory location. It is also more difBcult to correct 

Tot example, the functional unit 30 reads the source an cnor generated by an operation that affects die state of 

register R6 and if an exception has occurred, initiates a external hardware. For diese reasons, it is preferable to treat 

branch operation to an error handling routine. The source operations visible outside the processor as non-speculative, 

register for die check operation is die same as the renter to ^ ^ Using the approach of ttie second embodiment an instruc- 

bc checked for a deferred exception. The source register of require speculative and non-speculative 

die check operation may be the destination register of a versions of operations. As a result, speculative execution can 

speculative operation that has generated and deferred an supported in a manner that maintains con^>atibility widi 

exception, or of a ^>eculativc operation that has propagated ^n existing instruction set architecture. The operations that 

die deferred exception. In cither case, the source register diat ^ ^re treated as natively speculative and non-speculative vary 

is checked contains information about the deferred cxccp- ardiitocture of the CPU. In some systems, aU 

tion. operations txcxpi those visible outside die CPU can be 

A system for supporting speculative execution may be treated speculatively. In one alternative, all operations could 

implemented in a computer system 20 as described with t>e treated as natively speculative. In anodier alternative, 

reference to FIGS. 1-3. There are several alternative ways to 33 some operations could be natively speculative while others 

implement a system according to the invention. While two are provided as both speculative and non-speculative, 

specific embodiments will be described below, it should be a system according to the second embodiment may be 

understood tfiat odicr variations are possible and will be designed to be con^)atiblc with the binary form of a 

^iparent to those of ordinary skill in the art program, whether or not it has been (^timized using specu- 

A first embodiment of die invention includes encoding 60 lative code motion. To take advantage of die speculative 

speculative and non-speculative versions of operations in the execution supported in the CPU, programs are optimized 

instruction set architecture of the CPU. In this embodiment using speculative code motion to move operations for which 
die opcodes identify whether an operation is non-speculative the CPU has a speculative version. Two categcrics of 
or speculative. For example, die opcode 42 of die ADD programs may therefore exist: existing programs diat have 
operation in FIG. 3 could be encoded to designate die 65 not been (^timized using speculative code motion, and new 
operation as either speculative or non-speculative. The ver- programs that have been specifically optimized for the 
sion of die operations affects whettier an exception gener- speculative execution supported by the CPU. To maintain 
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compatibility with both programs, the CPU may include opcratioo a may include the addition of a separate check 
drcuilry to support a ooo-speculative mode and a natively operation. If operations visible outside the CPU are non- 
speculative mode. speculative, then a check operation could be incorporated 

If the CPU is to support both modes of operation, it must operations. For example as pwt of a 

include circuitry for recognizing whether a program has 3 optmoz, ihc funebonal umt 30 could check 

been optimized for speculative exeoition.TOs drcuilry may '^l^^t "S^*""" ^ "^ove «. memoiy store 

, t J u.-** _j V Operation has two source registers — oac that contains the 

include a regist« such as the status ^[d register where a aiuun to be stored in mei^ and one that contains the 

mode bit may be stored. Before the CPU begins execuuon ^ ^ ^ ^^^^ ^ 

of a program, it reads this register and switches to the ^ operation, checks both of its source registers for 

appropriate mode. The mode bit may be set in a vari<^ of lO ^^^^ propagated exceptions, 

ways. For e^lc if a program has been compil^ to 1^ ^^^^ ^ instruction in HG. 3, the 

advantage of speculative execuUon supported m the CPU, ^ ^^^^ ^^^^^^^ ^^^^^^ ^^^^^ 

then the operating system may be pro^ammed to set the semantics. As part of the memory store operation, the 

modebitAltOTatively,theco^ functional unit 30 would read the exception tag bit 38 of the 

the mode bit by identifying Ac mode in a status operation ^^^^ ^ ^ ^ detmnine 

placed in the binary form of the prograoL Many other ways ^^^^^ ^ exception has been deferred. If an exception has 

of specifying the mode of opwaton arc possible and will be ^^^^ ^^^^^ ^ opciatioa would then 

apparent to those of skiU in the art. ^^^^^ ^ ^ ^ ^^^^ 

While a system according to the second embodiment need ^ ^s another example, a separate check operation oould be 
not suppwt two modes of opaation, it is advantageous to created. This would involve encoding only one additional 
support two modes of operation to maintain con^tibility opcode for a check operation. These check opoations may 
with existing programs. If the CPU is to execute only be inserted during the scheduling process. Check operations 
programs that have been specifically optimized for specu- should be inserted so (hat each speculative operation that 
lative execution, then the CPU need not support a non- may generate or propagate an exception can be checked. The 
^)ecuUtive mode. An advantage <^ the second embodiment, ^^^^ register of the check operation may be the destinaUon 
however, is to maintain con^)atibiUty with existing instnic- register of the excepting operation. Also, the source register 
tion set ardutectures and j^ograms that have already been ^ ^ destination register of the last operation in a chain 
compUed to run on CPUs based on these architectures. If of propagated exceptions, lb ensure feat speculative opera- 
compatibflity with existing programs is in^rtant, then the ^^^^^ arc checked, check operations may be inserted after a 
CPU should support both a speculative and a non- speculative operation or after a chain of speculative opera- 
speculative mode of operation. tions. Because an exception is propagated to all <^>erations 

The first and second embodiments include architectural that use the result of a speculative operation that has 

support for deferring and reporting exceptions. This may generated an error, the check operation need not be inserted 

include an error tag bit 38 in the registers of the register files. for every speculative <^)eration. 

When an exception occurs in a speculative operation, the Referring again to FIG. 3, the third operation is an 

functional unit can set the earor tag bit to indicate that an example of a check operation that may be used to dieck for 

excq)tion has occuned. This exception is not reported deferred exceptions. This operation has only one source and 

immediately, but rather, is deferred. Information about the no destination register. If an exception has been deferred, the 
exception may be written in the destination register to assist ^ source register of a check operation contains information 

in error handling. This information may identify the that identifies the type of exception and operation that 

instruction, and the operation within the instruction, which generated the exception. When an exception is detected, the 

generated the exception. For exan^)ie, the information may information in the source register of the check operation 

uniquelyidentify the program counter value of the operation may be used to handle the exertion. TJ^^ically, when an 

that generated an exception. It may also identify tiie type of exception is detected, Ujc CPU branches to an exception 

exception such as an address violation, aritiimctic underflow handling routine. 

and overflow, etc. If another speculative operation uses the should be understood tiiat the foregoing discussion 

result of this operation as an input, tiicn the excq>tion is describes one of many possible ways of detecting and 

propagated. To propagate the exception, the error tag bit 38 reporting a deferred exception. As another alternative, a 
is set in the destination register, and the exception informa- ^ ^.^eck operation could check an operation at a memory 

tion is copied into the destination register. In this manner, the location to determine whetfiex the operation at this location 

system may defa- exceptions generated by speculative generated an exiOT. For example, the check operation could 

operations until the result of the operation is actuaUy used in operation in memory identified by its program 

the execution patii of tiie program. counter address. The check operation may be encoded to 
An error tag bit 38 is only one way of deferring an 55 check a program counter address such as "check operation 

exception. Other hardware may also be used. Fot example, at PC address 535" or "check Ae third last operation.'' This 

a speculative operation that generates an excq}tion can write form of check operation could be an alternative to checking 

information to a buffer identifying tiiat an exception has Uie destination register of a speculative operation. Since this 

occurred and including excq}tion information used in ciror check operation would not involve checking a destination 
handling. If the speculative instruction is actually used in the ^ register for a deferred exception, an additional buffer may be 

execution path of the program, dien the error infonnation used to store information about the type of exception used to 

can be read from the bu£fer, and the exception can be assist in error handling. 

handled accordingly. FIG. 4 is a flow diagram of a method far supporting 

A system constructed according dtfacr the first or second speculative execution according to an embodiment of the 
embodiment of the invention also includes architectural 65 invention. This diagram illustrates tiie operation of a system 

support for reporting deferred exceptions. This su[^>ort may for supporting speculative execution according to the first 

include a check function incorporated into a non-speculative and second embodiments of the invention. 
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la the first step 62, the operations arc scheduled. As set has occurred previously {66), If the operation is speculative 

forth above, the operations may be scheduled either dynami- (68), then the exception wiU be prc^gated by setting the 

caUv or statically, or pcrtiaps using a combination of both. error tag bit oi the result register and transferring exception 

As part of the schedulbg step 62, a check operation may be ioformatlon to the result Propagating an ^ccpdon m this 

kse^ktothehomebasiVblocksofo^ 5 fashion, die system defers the ex^^^ 

^e7 mo^ed above a conditional brCT In the first only if it is used m a . 

embodiment, the opcodes of speculative operations arc J^'^'^^'T^^ ""L"^^' ^^^^ 

ti*it/wi*uv«*, r reporting a defored exception. An exception is detected by 

encoded to distinguish them from ^en^ non-speculati^ operation (S) with eixor check- 

of the same operation. In the second embodiment a numto ^apW ^ting tlTtypc of operation includes 

of predctennincd operations arc treated as specukUve with^ lO deferred exception (66). TUe means for 

out being encoded as such. Once the program is scheduled, checking for a defened exception vary depending on the 

the CPU begins issuing opcratioos for cxccuUon. inq^lementation. Non-speculative operations may be iiiq)l6- 

An c^Kration is executed in the next step 64. In a CPU mentcd such that they chedc for a deferred excqjtion by 

with multiple functional units 30 as shown in FIG. 2, reading the error tag bit of an input or source register. Fbr 

operations may be issued to separate functional units simul- example, a memory store instruction may, as part of its 

tancously. If the functional units 30 arc also pipelined, semantics, read the error tag bit to check for a dcfcned 

several operations may be at varying stages of execution at exception and report an exception if one has been deferred, 

one time for each pipeline. As another exanqile, a check operation inserted into a home 

If an exception occurs during the execution of an opera- basic block may check for an exception be reading the error 
tion (66), then the system reacts differentiy depending on the ^ tag bit of a result register or registers of speculative opera- 
type of operation (68). For speculative operations, the tions from that home basic block. If an exception has been 
exception is deferred (70). For noo-speculative operations, deferred, the exception will be reported immediately (72). In 
however, the exception is reported and an error handling tiiis manner, the system for supporting speculative execution 
routine is initiated (72). Non-speculative operations arc defers exceptions generated in speculative operations, 
those operations that have not been moved above a condi- ^ Though the system and methods of tiic invention have 
tional branch, but ratha, remain in their home basic block. been described in detail in the context of alternative 
Depending on the implementation, non-speculative opera- embodiments, it should be understood tiiat the invention 
tions can include any type of operation. Examples of non- may in^>lemented in a variety of ways without departing 
speculative derations include memoiy store operations that from tiie scope of the invention. For example, tiic instruction 
^c not moved above a branch because they are visible ^ set architecture can inchide non-speculative and speculative 
outside the CPU. or a check operation that is inserted into the versions of operations, natively speculative c^>crations, or a 
home basic block of speculative operations to dieck for a combination of botii. The means toe deferring an exception 
deferred excq)tion. may vary depending on the CPU architecture. For cxan4)le, 

Depending on how the system is implemented, an opera- 3^ a single error tag bit may ^^^^^ 
tionUidentmed as speculative or non-speculative in differ- registers in a register file, or pcihaps abuffer could be used 
cnt ways. In tiie first embodiment, speculative and non- to keep track of defeired exceptions. lUe means for check- 
speculative operations are differentiated by their opcodes. In ing for deferred exceptioi^ may vary as well As ^cnbed^ 
&r^nd e^odiment. a predetermined number of opera- tiie hardware semantics of a CPU can be designed to check 
tions are treated as specuUtive operations without requiring ^ for deferred exceptions when <^^^J^J^^jyV^^ f J^^* 
special encoding of theopcxKles to speculative opera- speculative operations are Alternatively, a sepa- 
tions. The CPU recognizes these natively specuUtive opera- rate check operation could be added to the ^nsmiction set 
tions and defers exceptions generated by tiiem. Similarly, the architecture. Many oth<^ vanaUons to tiie embodiments are 
CPU recognizes the operations ttiat are natively non- possible without depaitmg from the scope of tiie mvcntion. 
speculative and immediately icpotts any errors generated by In view of tiic many possible embodiments to which the 
^gjj^ principles of our invention may be put, it is en^Jhasized that 

To maintain compatibility with existing programs, die tiic detailed embodiments described herein are niustrativc 

CPU rSl^ second embodhnent may have Iwo modes of only and should not be taken as hmiting tiie scope of ou^ 

operation: a speculative mode and a non-speculative mode. invention. Rather, we claim as our ^"vention aU su^ 

totiiespeculatiTemode^tiiepredcterminedsetofoperations ^ embodin:ients as may come witiun the scope and spim 

are tre^tedas natively speculative. Exceptions are deferred foUowing daims and equivalents tfiereto. 

for these natively speculative operations. In tiie non- We claim: 

speculative mode, tiie^edetermined set of operations are 1. A mettiod for supportmg specuUtive cxecuUon com- 

treated as non-spccuUtive and exceptions arc not deferred prising: 

for tiiese operations. 55 providing an instruction set architecture for a central 

It is possible to treat a number of opffations as natively processing unit including non-^ulative and specu- 

spJ^ve w^^al^^ encJSg speculative and lative operations, at least one of ^^^^^^^ 

^^ulative operations. For example, aU operations not tions bemg natively speculaUvc such tfiat the at least 

visibUoutside the CPU could be natively speculative while one natively specuUtve operation is not encoded as a 

all otiier operations such as a memory store could be eo speculative operation; 

provided in specuUtive and non-i^)ecuUtive versions. This scheduling operations in a c<Mnputcr program mcludmg 
^>proach is subject to tiie limitations of the particular tiie step of moving speculative operations above con- 
instruction set architecture, which may ot may not have ditional branches; 

enough flexibiUty to add additional opcodes. executing <^)erations in tiie central processing unit indud- 

The sequence of steps (64-70) may include propagating a 65 ing the steps of: 

deferred exception. At tiie execution step 64, tiie functional if tiic operation is a specuUtive opoation and generates an 

unit 30 reads die enor tag to determine whctiier an exception exception, ttien deferring ttie exc«^on;. and 
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if the operation is a noD-specuiativc operation and geo- 
erates an exception, then raiting the exception. 

2. The method of claim 1 wherein the providing step 
includes providing a predetennined set of operations in the 
instfuctioQ set architecture that are natively speculative 5 
operations. 

3. The method of claim 1 wherein the providing step 
includes providing a predetennined set of operations in the 
instnictioD set architecture {<x the central processing unit 
that are either all natively speculative or all non- speculative lO 
depending on a mode of the central processing unit; and 
further including the steps of: 

specifying the mode of die central processing unit by 
setting a mode bit in a status register of the central 
processing unit; *5 

and reading the mode bit in the status register to determine 
the mode of the central processing unit 

4. The method of claim 1 wherein the providing step 
includes providing a speculative and non-speculative ver- 
sion of a set of operations in the instruction set architecture. ^ 

5. The method of daim 4 wherein the speculative and 
non-speculative version of the set of operations are encoded 
in a set of opcodes, 

6. The method of claim 1 wherein the step of deferring an 
excq>tion includes storing information indicating that an 
error has occurred 

7. The method of claim 6 wherein the step of deferring an 
exception includes setting an error tag Ht In a result register 
of a speculative operation that gen^tes an exception. 

8. The mettiod of claim I wherein the step of executing an 
c^>eration includes diecking for a defeired exception. 

9. The method of claim 1 wherein the step of executing an 
operation includes propagating a deferred exception if die 
input of a second speculative operation is a result of a first 
speculative operation that has generated an exception. 

10. The meftod of claim 1 wherein the step of executing 
an operation includes executing a non-speculative operation 
to check for defeired exceptions. 

11. The method of claim 10 wherein the non-speculative 
operation includes a check function for checking for 
deferred exceptions. 

12. The mcUiod of claim 10 wherein the non-speculative 
operation is a check operation inserted in a home basic block 
of an associated speculative operation to check for a 
deferred exception firom the associated speculative opera- 
tion. 

13. The method of claim 1 wherein the scheduling step 
includes inserting a check operation in a home basic block 
of a speculative operation to check for deferred exceptions. 

14. A method fa: supporting speculative execution com- 
prising: 

providing a predetermined numt>cr of speculative opera- 
tions in an instruction set architecture of a central 
processing unit; 
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specifying a mode of the central processing unit by setting 
a mode bit in a register of the central processing unit; 

reading the mode bit in the register to determine the mode 
of tiie central processing unit and if the mode bit 
indicates that the speculative operations arc to be 
operated as non-speoilative operations, then 
operating the speculative operations as non-speculative 
operations; 

otherwise* executing speculative operations and if an 
excq>tioa is generated &om a speculative operation 
toen 

deferring the exception by storing information that 

identifies that an exception has occurred, 
executing a non-speculative operation including a 

check operation to check for a defeired exception, 
checking for a deferred exception by reading a 

destination register of a speculative operation, and 
if an exertion is detected in a non-speculative 

operations » then reporting the exception. 

15. The method of claim 14 wherein the providing step 
includes providing a q>eculative and non-speculative ver- 
sion of a set of operations in an instruction set architecture 
by spedAcaliy encoding opcodes of the operations in the set 
to identify whether an operation is ^culative or non- 
speculative. 

16. A system for supp<ating speculative execution com- 
prising: 

a register file including a general purpose register and 
a functional unit in communication with the register file 
for executing operations, the functional unit including 
circuitry for recognizing speculative and non- 
speculative operations, the functional unit in commu- 
nication with the register file for storing information 
indicating that an exception has been deferred if a 
speculative operation generates the exception, and for 
checking for deferred exertions; 
wherein the circuitry for recognizing speculative and 
non-^culative operations includes a register for stor- 
ing a mode bit identifying a mode of die central 
processing unit and further includes circuitry for read- 
ing tiie mode bit to determine whrther an operation is 
to be treated as a speculative or non-speculative opera- 
tion. 

17. The system of claim 16 wherein the circuitry for 
recognizing speculative and non-speculative operations 
indudes circuitry for reading an opcode of an operation to 
determine whetiier the opcode is a speculative or non- 
speculative version of the operation. 

18. The system of claim 16 wherein the functional unit 
indudes circuitry for signalling a deferred exception. 

19. The system of claim 16 wherein registers in the 
register file include an error tag bit for indicating whether an 
exception has been deferred. 
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